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DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 12/08/06. 

As indicated in Applicant's response, claim 15 has been amended. Claims 1-30 are 
pending in the office action. 

Claim Objections 

2. Claim 19 is objected to because of the following informalities: 

The use of phrase such as 'passage of a parameter', in light of the known concept of 
parameter passing, needs to be readjusted because the parameter is not actively executing its own 
passage (passage as in the act of passing) but actually is being subjected to a process or 
instruction that passes it. That is, the object (e.g. procedure parameter) being passed is target 
being operated upon, and the passing process acting upon the object target, the passing 
instruction being the actor that performs the passage of such object or parameter (because a non- 
executable parameter cannot be an actor): thus inappropriate language. The deficiency will be 
treated as though the second subroutine includes a variable referred to by reference, the variable 
destined for a passing process or instruction. 

Appropriate correction is required, lest an indefiniteness (or non-enabling) type of 
rejection be effectuated. 

Claim Rejections - 35 USC §101 

3. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new 
and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. 

4. Claims 1-6, 15-18, 22-26 are rejected under 35 U.S.C. 101 because the claimed invention 
is directed to non-statutory subject matter. 
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The Federal Circuit has recently applied the practical application test in determining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, 
concrete, and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a 
patent. As a consequence, an invention, which is eligible for patenting under 35 U.S.C. § 101, is in the 
"useful arts" when it is a machine, manufacture, process or composition of matter, which produces a 
concrete, tangible, and useful result. The test for practical application is thus to determine whether the 
claimed invention produces a "useful, concrete and tangible result". 

The method of claim 1 recites executing first and second module, each including 

instructions that causes variable loading, parameter passing, or parameter accessing using offset 

operation. As a whole, the method amounts to internal working of computer execution and there 

is no reasonable conveying that by obtaining the result of this execution, some application is 

perceived as yielding a real-world concrete result, in terms of it being tangible, and useful. That 

is, the claim as a whole, for merely reciting that some module is being executed without 

providing what would benefit from such execution so to lead to a result as required from the 

Practical Application Test, does not amount to a internal abstract computer data, not a real world 

useful result. Therefore claim 1 and claims 2-6 are rejected for leading to a non-statutory subject 

matter. 

Claims 22-26 amount to computer instructions stored in a media to execute instructions 
in the same manner as claims 1-6; hence fail to provide a tangible result based on such execution 
when there is insufficient teaching as to how this execution would interact with any application 
for users to benefit of its result, particularly when there is no result being reasonably conveyed 
from the claims as a whole as being concrete, useful and tangible, absent any form of application 
via which a user can perceive such result. 

Claim 1 5 recites a system comprising a compiler. This compiler is disclosed ( refer to 
Specifications pg. 7, first line) as being software application, hence the claimed system amounts 
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to just a software entity having some function, and so without any hardware support to realize 
such functionality. The claim as a whole cannot be construed as able to generate real-world 
result when the software is not disclosed as being executed via computer tangible support. 

Claims 15-18 together fail to provide a result as required by the Practical Application 
Test, and are rejected for leading to a non-statutory subject matter. 

Claim Rejections - 35 USC § 112 

5. The following is a quotation of the first paragraph of 35 U.S.C.§ 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

6. Claims 3, 17, 24 are rejected under 35 U.S.C.§1 12, first paragraph, as failing to comply 
with the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. 

Claim 3 recites that the parameter (from claim 1) is not pushed into the stack 'as part of 
the call from first module to the second module'. From the Specifications, Figure 4 shows 
procedure A as having parameter passed by reference, and these parameters appear to be on the 
stack as part of the calling stack using the Base Pointer and the return address, all of which being 
part of Figure 6B wherein procedure A is being called (line 674) and variables needed for this 
function call are pushed on the stack ( see pg. 15 block 802). Therefore, as part of this calling 
instruction, line 674, Fig. 6B, the local variables are pushed into the stack and this is construed as 
being known concept from the prior art of Figure 1 and 2. Further, steps 642-Fig. 6B and step 
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606-Fig. 6 A lead to the rationale that the call from the first module to the second module 
contains in its part a pushing of a parameter/variable (see psuhl) onto the stack, such parameter 
being just an address %ebp, hence a parameter passed by reference ( Note: step 606 being part of 
the calling from step 650 in the main flow of Fig. 6B is perceived as part of call from the first 
module to the second module). Hence, it appears that the variables are to be pushed in order for 
them to be part of the calling instruction, in regard to which a same calling instruction form is 
depicted in line 110 of Figure 1 and line 414 of Figure 4. Apparently, in the Drawing examples 
as disclosed, the call from the main process to A_RFCiTO ( see Fig. 6B) is not described 
sufficiently as to set forth a context where one skilled in the art can see how a 'part of a call' has 
been implemented. The Main procedure loads a reference to memory (line 642, Fig. 6B); and 
distinct from it, the A_FRCiTO proc loads another instance of %ebp ( line 606) such that when 
line 674 is executed, one cannot see what part of this calling ( call A_FRCiTO, Fig. 6B) has 
some internal implementation that dictates what the claim recites: the parameter not pushed onto 
the stack. The claimed language leads to a interpretation that is not commensurate with the 
Specifications, but rather render any attempt to grasp an inventive concept more difficult; and 
one skilled in the art would not be able to construe this limitation {not pushed into the stack ... 
part of the call) based on what the Disclosure description of the calling of A (Fig. 1, Fig. 6A, 6B, 
7); and the claim is rejected for failing to provide appropriate description to convey that the 
inventor has possession of this specific limitation. 

The limitation will be treated as though the parameters are pushed into the stack to 
support the passing by reference ( i.e. as part of the calling of A) but not pushed any more at 
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runtime where a pop instruction would be needed; as shown in Figure 1 or Figure 4 of the 
Specifications. 

Claims 17 and 24 recite the limitation of claim 3 and are rejected for the same rationale. 

7. The following is a quotation of the second paragraph of 35 U.S.C.§ 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

8. Claims 7-14, 19-21, 27-30 are rejected under 35 U.S.C.§1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

Claim 7 recites 'generate compiled instructions . . . do not include instruction to load the 
variable onto a stack, during execution, based on the call instruction' (last paragraph). It is noted 
that stack is dynamic structure to save address values of runtime call, i.e. stack for push/pop 
operations during execution ; and based on the teaching of Figure 1 and Figure 4, values of 
parameters are seen as being pushed into the stack for supporting the call by reference as 
described in the claim. Based on the calling of a function in which parameters ( see 
Specifications: function A in Figure 1 & Figure 4) as mentioned above in the rejection using 
USC§1 12, 1 st paragraph, it is unclear as to how not including loading of the recited variable - 
variable as being passed by reference - has been effectuated during stack runtime, in the context 
of a part of a call as recited (refer to the above Claim Rejection, USC§1 12, 1 st paragraph). Claim 
7 recites the variable as a parameter of other parameters; hence it is reasonable to interpret the 
loading of a parameter to be same as loading a variable on the stack during the first call that will ■ 
calls a function that passes by reference. And this paradigm is illustrated, for example, in steps 
642 Fig. 6B and step 606, Fig. 6A supports to the following understanding: step 606 being part 
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of the calling from step 650 in the main flow of Fig. 6B, with loading of parameters into a stack. 
It is not sufficient to enforce a patentable weight by way of claiming that some feature will not 
be there without specifying details going about how to enable it (emphasis added) to happen, and 
the 'do not include... onto a call stack' limitation is not sufficiently enabling given the above 
observation. One skill in the art would not be able to make use of the claimed invention in light 
of the stack being loaded with the very variables such that it would become part of the calling of 
function A (see above). The limitation is rejected for indefinite teaching as to how the subject 
matter as recited enables a clear and non-contradictory understanding. 

Claim 19 and 27 recite this 'do not include . . . load the variable' limitation; thus, are 
likewise rejected for reciting a limitation that render the teaching of the claimed subject matter 
indefinite, contradictory, unsupported, inconsistent with the Disclosure, hence not setting a clear 
metes-and-bounds teaching for one skill in the art to make use of the subject matter. 

The limitation will be treated as though the variables are in the stack based on the call of 
the function. 

Claims 8-14, 20-21, 28-30 do not appear to cure the deficiency of the respective base 
claims; and are also rejected. 

Claim Rejections - 35 USC §102 
9. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this 
or a foreign country, before the invention thereof by the applicant for a patent. 
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10. Claim 1-5, 7-1 1, 13-14, 19-25, 27-30 are rejected under 35 U.S.C. 102(a) as being 
anticipated by Tomasz Muldner, 'C++ Programming with Design Pattern Revealed', 
< http://wwwxs.helsinki.f^ Addison Wesley, 

Copyright 2002, pp. 1-42 (hereinafter Muldner) 

As per claim 1, Muldner discloses a method comprising executing an executable 
program that comprises: 

executing a first module (Main Function , pg. 1), wherein the first module includes a 
second instruction that calls a second module (e.g. Pass by Reference: swap (int &x, int &y) - 
pg. 16) that passes a parameter by reference, wherein the parameter passed by reference is an 
address of the variable; and 

The concept of loading into a stack an address location of a function being called and 
using it as a base pointer or base index to calculate additional distance so to reach for other 
addresses (based on a & reference ) in effecting a call has been known in the C/C++ 
programming ( see Admitted Prior Art or APA: See Specifications: Figure 2) and was known 
concept. Hence, this loading of a base pointer from the calling function (e.g. a Main Function 
entry point at which the function is invoked) to a invoked function/subroutine (see swap ( &x, 
&y) so that the function being called use such BP to retrieve the value of x or y in a deferencing 
process is also disclosed as being integral to the Admitted C/C++ programming language. 

In view of the above, Muldner, by way of pg. 16 does show that the first module includes 
a first instruction that causes a variable to be loaded onto a stack executing the second module 
that includes a third instruction that accesses the parameter on the stack based on an offset ( 
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another distance to calculate from where the swap is called) from a common reference (entry 
point from main at which swap is called) for the second module. 

As per claim 2, Muldner by virtue of the rationale in claim 1 , discloses executing the 
second module that includes the third instruction that accesses the parameter on the stack based 
on the offset from a base pointer for the second module (see Admitted Prior Art: Specifications, 
Figure 2). 

As per claim 3, Muldner discloses by virtue of claim 1 and APA ( see Specifications, 
Figure 1), wherein the parameter is not pushed onto the stack as part of the call from the first 
module to the second module (parameter x, and y being pushed earlier -see APA: Specifications, 
Fig. 1) reads on not being pushed again during effecting of Muldner' s calling of swap (Pass by 
Reference: swap (int &x, int &y) - pg. 16). 

As per claim 4, see Muldner for the first instruction that causes the variable to be loaded 
onto the stack comprises executing the first module that includes the first instruction to define 
the variable (see APA: Specifications: Fig. 2, 2 nd para, pg. 2) or Muldner( Pass by Reference: int 
i=l;int j=2, pg. 16). 

As per claim 5, see Muldner (swap (int &x, int &y) - pg. 16) wherein the first module 
calls the second module through a third module, wherein a first calling sequence comprises the 
first module, the third module and the second module (Note: any submodule being called by 
another function in a C/C++ Main program reads on sequence involving first, second and third 
modules called in sequence as recited). 

As per claim 7, Muldner discloses a method comprising: receiving a program code that 
includes 
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a first calling function having a call instruction to call a first called function that passes, 
by reference (swap (int &x, int &y) - pg. 16), a variable as a parameter of a number of 
parameters (Note: passing an address that needs to be dereferenced reads on starting parameter 
leading to other parameters OR see Specifications: Figure I, BP - Note: loading stack with a 
subroutine base pointer as by APA reads on Muldner C/C++ language with using of such base 
pointer parameter as parameter representing starting point for subsequent parameter fetching); 
and 

compiling the program code to generate compiled instructions, wherein the compiled 
instructions do not include a compiled instruction to load the variable onto a call stack, during 
execution, based on the call instruction (re rationale in claim 3 ). 

As per claims 8-10, Muldner discloses wherein the first calling function has a declaration 
instruction to allocate the variable, wherein the compiled instructions are to cause the variable to 
be loaded onto the call stack, during execution, based on the declaration instruction (see APA: 
Specifications: x, y, z - Fig. 2, 2 nd para, pg. 2) or Muldner ( Pass by Reference: int i=l; int j =2, 
pg. 16); wherein the called function includes an access instruction, wherein the compiled 
instructions are to cause the variable to be accessed from the call stack, during execution, based 
on the access instruction ( Note: swap (int &x, int &y based on BP of APA - .Specifications Fig. 
2 — reads on cause to access from the stack during execution by the called function), wherein 
the compiled instructions are to cause, during execution, the variable to be accessed using* a base 
pointer (see APA: BP, Fig. 2) associated with the called function. 

As per claim 11, refer to rationale of claim 5. 
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As per claim 13, Muldner discloses wherein an order of the number of parameters passed 
by the first calling function equals an order of the number of parameters passed by the second 
calling function ( see Passed by Reference, pg. 16 - Note: the number of dereferencing by the 
called function based on the reference being passed by the calling functions reads on the above ). 

As per claim 14, in light of the rationale as set forth in claim 12, the limitation as to 
cause an order of the number of parameters on the call stack for the first calling function include 
parameters for the first called function and parameters for a second called function and wherein 
an order of the number of parameters on the call stack for the second calling function include 
parameters for the first called function and parameters for a third called function, wherein a size 
of the parameters for the third called function are not greater than a size of the parameters for the 
second called function would have been disclosed, in light of the necessary mapping of 
parameters from one calling function to the next calling function to the called function; because 
otherwise a mismatch would have resulted in a exception by the C/C++ at runtime or linking 
time. 

As per claim 19, Muldner discloses a system having subject matter corresponding to that 
of claim 7, comprising a secondary storage to store at least a part of a source code program, 
wherein 

the source code program includes a first subroutine that includes a first instruction to 
define a variable and a second instruction to call a second subroutine, wherein the call to the 
second subroutine includes passage of the variable by reference; a dynamic random access 
memory to store at least a part of a call stack; and 
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a processor to compile the source code program to generate assembly code instructions, 
wherein the assembly code instructions do not cause the variable to be pushed onto the call stack 
based on the second instruction; 

all of which limitations having been addressed in claim 7, the source code storage prior to 
compilation reads on secondary storage; and the dynamic RAM storage reads on runtime using 
stack ( see APA Fig. 2 in light of the passing by reference in claim 1). 

As per claims 20-21, refer to claims 8-9. 

As per claims 22-25, these claims correspond to claims 1-5, hence will incorporate the 
corresponding rejections, respectively. 

As per claims 27-30, these claims correspond to claims 7-10, hence will incorporate the 
corresponding rejections, respectively. 

Claim Rejections - 35 USC § 103 

1 1 . The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that 
the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary 
skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

12. Claims 6, 12, 15-18, and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Muldner, 'C++ Programming with Design Pattern Revealed', in view of R. Stallman, GNU 
CC, 'Using and Porting GNC CC, < http://web.umr.edu/-gnudoc/split/egcs/gcc toc.html > - 
copyright 1988-1996 (hereinafter GNUCC - Part 1: Target Description Macros pp. 1-40; Part 
2: Defining the Output Assembler Language, pp. 51-66). 
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As per claim 6, Muldner does not explicitly disclose that wherein a second calling 
sequence comprises the first module, a fourth module and the second module, wherein executing 
the first module comprises padding the stack such that the number of entries on the call stack are 
the same for the first calling sequence and the second calling sequence. But C/C++ language 
includes freeing memory in view of leakage; and one example is disclosed in the GNU CC 
compiler wherein padding of extra unused stack memory is disclosed via a particular compiler 
macro routine (see Part 1, Passing Arguments in Registers: function_arg_padding (mode, 
type) - pg . 30 ) . Based on Muldner' s C/C++ usage, it would have been obvious for one skill in 
the art at the time the invention was made to pad unused stack memory based on passing by 
reference (as opposed to passing by value) paradigm wherein space saving is suggested, because 
unused space as purported by C/C++ programming would be much enhanced when used with 
compiler such as GNU with compiler macro capability to provide such padding when unused 
space left by function calls is detected by GNUCC macro as set forth above. 

As per claim 12, the subject matter having C/C++ compiler with enabling compiled 
instructions as having a compiled instructions to pad the call stack such that the number of 
entries on the call stack are the same for the first calling sequence and the second calling 
sequence falls under the ambit of the subject matter of claim 6; hence is rejected with the 
rationale as set forth therein. 

As per claim 15, Muldner discloses an apparatus comprising to generate code 
instructions wherein the instructions comprise a first procedure and a second procedure, wherein 
the first procedure includes a first assembly code instruction to cause the variable to loaded onto 
a call stack, wherein the first procedure instruction to cause the second procedure to be called, 
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which includes passage of a parameter by reference, wherein the parameter passed by reference 
is an address of the variable (e.g. Main Function , pg. 1; Pass by Reference: swap (int &x, int 
&y) - pg. 16), the second procedure to include a third assembly code instruction that is to access 
the parameter on the stack based on an offset from a common reference associated with the 
second procedure ( this limitation of using a base pointer on the stack would be disclosed 
because that is how C/C++ stack is used according to known concept of calling function as set 
forth in APA, wherein the BP of Specifications Fig. 2 reads on the common reference). 

But Muldner does not explicitly disclose a compiler to generate assembly code 
instructions, wherein the assembly code instructions. A compiler to generate assembly code for 
debugging purpose, platform architecture matching or for porting is suggested in Muldner 
attempt to port C++ code. And GNUCC discloses compiler option to create assembly 
instructions and passing compiler instructions/options to this assembler (Part 2: Output to 
Assembler Language, pg. 51-65). It would have been obvious for one skill in the art to provide a 
compiler generating assembly instruction codes as purported by GNUCC in light of the porting 
endeavor by Muldner, because implementing target code toward an architecture specific machine 
language can be visualized via assembly language as this can support Muldner' s compiler to 
utilize its debugging options so to correct issues relevant to any target architecture via this step of 
using an assembler. 

As per claims 16-17, see APA in light of Muldner' s C/C++ language and rejection of 
claim 3. 

As per claim 18, in light of claim 15 in regard to compiler for assembly instructions, see 
Muldner (pg. 1-2, pg.16 ), wherein the first assembly code instruction is to define the variable. 
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As per claim 26, this claim corresponds to claim 6, hence is rejected with the same 
rationale as set forth therein. 

Response to Arguments 

13. Applicant's arguments filed 12/8/06 have been fully considered but they are not 
persuasive. Following are the Examiner's observation in regard thereto. 
Claims Objections: 

(A) For claim 19, Applicant's attempt (Appl. Rmrks, pg. 9) to use Webster's definition to 
maintain the use of passage of parameters in light of known practices of parameters passing is 
deemed non-persuasive; because passage of something that is actually performing its own 
passing is different from passing by reference wherein the instructions is executing the passing 
while the parameters just happen to be moved by the act of passing, i.e. the parameters cannot 
execute their own passage. 

35 USC §101 Rejection: 

(B) Applicant has submitted that loading and accessing of a call stack during execution is 
useful in the context of program execution, which thereby renders the claimed method tangible 
as in a real-world result relative to a call stack ( Appl. Rmrks, pg. 10, middle). A set of data 
being loaded into any runtime is only useful to the timeframe of said runtime; and with respect to 
the rest of the computer such stack creation is not much persistent than a Java thread. An 
application level realization of a useful, concrete and tangible result requires reasonably 
establishing/achievement of some sort beyond a short-lived creation of stack data in procedure 
call setup. The claim stops short as executing first and second module without definite action 
using the result from such execution in terms of useful application level in a way that a tangible 



Application/Control Number: 10/677,081 Page 16 

Art Unit: 2193 

and useful result is perceived (at the level of the user applying the invention into a practical use). 
Let's suppose that the Invention has some features of some weight, the mere fact of executing 
such feature internal to the volatile level of a stack storage of a computer runtime does not 
suffice to give statutory status to these features in view of the Practical Application Test 
requirements. Even one thorough description of program execution events inside a runtime 
would not suffice to bring forth this tangible Practical Application result as required; because 
every program execution implicates innumerable combinations/varieties of actions underlying 
the program execution with unstable memory states; thus, depicting those combinations as 
claimed features would be inappropriate because there would be (and incorrectly so) then 
innumerable combinations of potentially patentable inventions. The rejection is maintained 
because the argument is non-persuasive. 

35 USC §112 Rejection: 
(C ) Applicant has submitted that in view of what is disclosed at page 9, lines 12-30, it is 
proven that regarding part of the call from the first module to the second module the Disclosure 
describes what is claimed (Appl. Rmrks, pg. 11, middle). As mentioned above, the main 
procedure load a variable into a stack, the AFRCiTO also loads a same instance into a stack, 
such that when line 650 gets executed (Fig. 6B) it is unclear to construe that such call has a part 
designed particularly (emphasis added) so that no parameter has been loaded onto the stack, not 
withstanding the fact that the claim remains unspecific as to what exactly distinguishes a 
parameter loading from a variable loading when (emphasis added) line 650/606 of A_FRCiTO 
(see Fig. 6A-B) and line 642 of Main appear to load an identical entity onto the stack. The 
Specifications describes a more elaborate scenario according to which: some variables loading 
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occurs at some address of a stack, and so irrelevant of the execution of first module calling a 
second module; some address is loaded into a runtime Main, the same address is implemented 
via a load instruction inside a procedure that will be invoked by the main; and based on the 
address ( or LHS content) as loaded in the Main, the procedure when called by the Main retrieves 
a basis for appending offset to yield location to obtain the needed parameters, the RHS content of 
the parameters defined by the variables loaded in the first place. The claim language used is not 
remotely commensurate with the scenario from the Disclosure. And the limitation referred to as 
'part of the call' is nowhere described in the Disclosure to support the 'not pushed onto the 
stack' feature. The argument is not persuasive. Applicant's arguments do not comply with 37 
CFR 1.1 1 1(c) because they do not clearly point out the patentable novelty which he or she thinks 
the claims present in view of the state of the art disclosed by the references cited or the 
objections made. Further, they do not show how the amendments avoid such references or 
objections. 

(D) Regarding 35 USC §112, 2 nd paragraph argument ( Appl. Rmrks, pg. 11, bottom), these 
fall under the ambit of insufficient teaching as observed above in section C; and will be treated 
based on section C. 

USC 35 §102 Rejection: 

(E) Applicant has submitted that APA does not include an instruction for accessing any of the 
parameters based on an offset (Appl. Rmrks, pg. 12, bottom). The claim does not specify what 
'based on a offset' and 'common reference for the second module' amount to, respectively, in 
light of the steps already achieved and taken in the method claim (executing first and second 
module). For one skilled in the art, an offset represents a distance from a base address; and the 
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entry point (e.g. an address in the Main Function) when a function is invoked (at which 
parameters are to be retrieved - as per Specifications: Fig. 2; or Muldner's Swap function) is 
considered the common reference (for the invoked procedure) from which a distant location is to 
be calculated (e.g. function B in Fig. 1 of Specs; or swap in Muldner) via a reference in the stack. 
As compared to the insight provided from scanning the Specifications, the claim seems lacking 
specifics about (i) loading an address (LHS - pass by reference) which necessarily distinguishes 
from loading a empty placeholder or a variable (RHS); (ii) loading an offset value into a stack; 
(iii) providing one or more instruction(s) that utilizes the LHS reference and/or the RHS and the 
offset; (iv) effectuating a call that utilizes all of the above in a clear sequence; (v) clearly 
defining what is a base reference with respect to all the loading and offset thus mentioned. The 
claim has to be self-sufficient to establish the inventive concept, not requiring importing the 
Specifications into it, or reading between the lines of empty broad terminology. The claim is 
definitely not commensurate with the Applicant's proffered explanation, which appears to be 
preconceived insight derived from outside the broad interpretation otherwise permitted by the 
claim as it has been explicitly termed (Note: an Offset value to be added from an based address 
location to obtain some actual address remains to be explicitly claimed as opposed to broad 
terms). The inaccuracy resulting from the combined limitations recited as 'offset' and 'a 
common reference for the second module' contribute to a broad interpretation that leads to the 
reasonable mapping as explained in the rejection; and herein above. Applicant's arguments fail 
to comply with 37 CFR 1.1 1 1(b) because they amount to a general allegation that the claims 
define a patentable invention without specifically pointing out how the language of the claims 
patentably distinguishes them from the references. 
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(F) Applicant has submitted that by virtue of the variables (x, y, z) being again pushed onto 
the stack as per APA, APA does not disclose 'not pushed onto the stack . . . part of the call' ( 
Appl. Rmrks, pg. 13). This 'not pushed onto the stack' limitation has been addressed at length 
above; and remains unclear, as set forth in the Rejections, in terms of reasonably deliberate and, 
unequivocal, accurate depiction from the Specifications. Broad interpretation has been used 
because the above limitation has no real weight; and Muldner's parameter x, and y being pushed 
earlier -see APA: Specifications, Fig. 1— reads on not being pushed again during effecting of 
Muldner's calling of swap. The argument is therefore not sufficient to overcome the rejection. 

(G) Applicant's arguments ( Appl. Rmrks, pg. 13-14) for claim 7, 19, 22, 27 and related 
dependent claims is referred to the response set forth for claim 3 in the above sections E and F, 
correspondingly. 

35 USC§103(a) Rejection: 

(H) Applicant has submitted that Stallman's padding with extra space in a argument passing 
is not disclosing what is claimed as 'padding the stack . . . number of entries on the ... call . . . 
same for first ... sequence ... second ... sequence'; and that the Examiner's assertion of prior art 
disclosure amounts to an unjustified Official Notice ( Appl. Rmrks, pg. 15, bottom, pg. 16 top). 
First, it is noted that stack entries is treated each as a fixed space in a given location of stack, 
whether it is half-filled, full or empty. Second, first call sequence or second call sequence is 
treated as sequence of atomic spaces more or less filled in the above stack location when a call to 
a function necessitates reading from the stack entries, like a amount of bits occupied by a 
parameter being stored. Since a fixed number of space is pertinent to each stack entry, a 
parameter referred to by a call relates to the occupying status of such amount of stack entry 
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spaces; so that by padding one argument ( or parameter stored in one stack entry) as done by 
Stallman, the extra atomic spaces not filled by one stack entry are then padded to that one 
sequence will be same as the another sequence, by virtue of which padding all sequences of 
atomic spaces (for each parameter related atomic spaces) fill the above fixed spaces. Stallman 
therefore teaches 'padding stack entries . . . number of entries . . . same for both the first ... 
sequence and second ... sequence'; and if so, then the alleged use of Official Notice would be 
very futile, rendering the Affidavit request equally unnecessary. The rationale of 35 USC 103 
joins teachings of references and the reason for such combining as well as the benefits to do so 
have not been identifying (from the above argument) as improper; and Applicant's main concern 
about a non-existent Official Notice regarding just Stallman is deemed not fulfilling what it takes 
to overcome a rationale for obviousness. In response to applicant's arguments against the 
references individually, one cannot show nonobviousness by attacking references individually 
where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 
208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 
1986). 

For the above reasons, the claims stand rejected as set forth in the Office Action. 

Conclusion 

14. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Meng-Ai An can be reached on (571)272-3756. 
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The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 



Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



272-3609. 
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